在用 AI 輔助開發的過程中，很容易掉入「AI 產出什麼就直接用什麼」的陷阱。然而，AI 生成的程式碼或 Schema 往往只滿足了最基本的語法需求，卻可能忽略了真實業務邏輯、安全性或效能細節。

今天來回顧在設計 library_system 資料庫時，Claude 產出的第一版 Schema 存在哪些潛在問題，以及我做了哪些修正與優化，目的是梳理當初為什麼要這樣設計，所以不用做更改。

第一版與最終版的對比與修正

1. 欄位命名與唯一性限制
   • AI 初版寫法：books 的 isbn 與 members 的 email 僅宣告為普通 VARCHAR。
   • Day 8 最終修正：加上 UNIQUE 約束。

     email VARCHAR(255) NOT NULL UNIQUE
     

   • 修改原因：每一本書的 ISBN 與會員 Email 在現實中都是獨一無二的。在資料庫層級設定 UNIQUE 才能提供最後防線，防止因程式碼漏寫檢查而寫入重複的髒資料。
2. 外鍵約束與刪除行為
   • AI 初版寫法：使用預設匿名外鍵，未指定刪除行為：

     FOREIGN KEY (member_id) REFERENCES members(id)
     

   • Day 8 最終修正：改用具名外鍵並加上 ON DELETE CASCADE：

     CONSTRAINT fk_loans_member FOREIGN KEY (member_id) REFERENCES members(id) ON DELETE CASCADE
     

   • 具名外鍵（如 fk_loans_member）能讓未來的資料庫維護與刪除更清晰；加上 ON DELETE CASCADE 可在刪除測試會員或書籍時自動清理對應的借閱紀錄，避免產生孤立無效資料。
3. 書籍庫存拆分為 total 與 available
   • AI 初版寫法：只提供單一 quantity（數量）欄位。
   • Day 8 最終修正：拆分為 total（總館藏數）與 available（目前可借數量）。
   • 修改原因：若只有單一數量欄位，借書直接扣減後會失去「原本總館藏數」的資訊。拆分後才能正確算出目前被借出多少本，符合真實圖書館的庫存管理邏輯。
4. 密碼欄位長度擴充
   • AI 初版寫法：members.password 設定為 VARCHAR(50)。
   • Day 8 最終修正：擴充至 VARCHAR(255)。
   • 修改原因：現代 Web 開發絕對不能儲存明文密碼，未來使用 PHP 的 password_hash() 加密後（如 bcrypt），雜湊字串長度常超過 60 字元。長度若給不足會導致字串被資料庫裁切，使會員無法登入。

與 AI 協作的心法總結

1. AI 是優秀的助手，但你是架構師：AI 可以在幾秒內寫完繁瑣的 SQL 語法，但商業邏輯的嚴密性（例如庫存怎麼算、密碼怎麼存）必須由開發者親自確認與引導。
2. 約束（Constraints）要下在資料庫端：不要過度相信前端或後端的防錯，資料庫層級的 UNIQUE、NOT NULL 與 FOREIGN KEY 是資料安全的第一道堅固防線。

完成這 10 天的探索，已經將 WSL2 開發環境、MySQL 資料庫 Schema、具名外鍵約束以及 seed.sql 測試資料已經都準備好了！

從明天開始，我們將正式進入 「核心功能開發」 階段，將撰寫第一個 PHP 程式，正式開啟 PHP 與 MySQL 資料庫的第一次對話！